Info-Atari16 Digest Fri, 12 Apr 91 Volume 91 : Issue 206 Today's Topics: 1.2 GIG drive Atari cpu evolution CAD 3D create and read in C? Defunct Power Supply Flash & QuickST Flash and QuickST, continued Forem BBS for sale Okami English manual PgC 7600 details PostScript printing Shareware and programming SIMPLE terminal emulator (2 msgs) SPURT (2 msgs) ST and RC stuff The language named C (2 msgs) TOS 2.05 bugfix ZEST [really EMULA] Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 12 Apr 91 00:50:18 GMT From: noao!ncar!asuvax!ukma!rex!wuarchive!uwm.edu!ogicse!milton!alexd@arizona.edu (Alex Danilchik) Subject: 1.2 GIG drive To: Info-Atari16@naucse.cse.nau.edu I have the chance to get a deal on a 1.2 gig Micropolis.. Anybody know if currect versions of Supra (which i have) or ICD or BMS and TOS 1.4 (of course) can handle a drive this large? cheers! gunnar alexd@milton.u.washington.edu ------------------------------ Date: 9 Apr 91 22:47:00 GMT From: mcsun!ukc!slxsys!ibmpcug!mantis!mwowm!mathew@uunet.uu.net (mathew) Subject: Atari cpu evolution To: Info-Atari16@naucse.cse.nau.edu In <1991Apr3.115106.4220@hemel.bull.co.uk>, Keith Bedford writes: >Re the Pgc cpu - see Byte March 89 (maybe only the International edition?) >for more details. Indeed, it's only in the "International" edition, since it's a well-known fact that Americans aren't the slightest bit interested in anything which is happening in Europe. The so-called "International" section of Byte is one of the many reasons why the magazine sucks. mathew -- If you're a fan of John Foxx, please mail me. ------------------------------ Date: 12 Apr 91 04:22:14 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!ucivax!gateway@arizona.edu Subject: CAD 3D create and read in C? To: Info-Atari16@naucse.cse.nau.edu Can somebody please send me some examples in C source on how to create and playback DLT files (CAD 3D animation file)??? For example, how do you XOR two frames together to get the difference and then how do you playback the file?? Thanks in advance Bill Ferrer bferrer@bonnie.ics.uci.edu ------------------------------ Date: Fri, 12 Apr 91 11:17 GMT From: MIKE Subject: Defunct Power Supply To: INFO-ATARI16@naucse.cse.nau.edu I have an early St (1985) with an external power supply. This is now defunct,in that the +5v output no longer works. Does anyone know if I can get a new supply, or point me in the right direction for repairing it. Sources for a new power supply would be preferable in the U.K. but I'm open to suggestions. Thanks Mike Jenkins (JENKINSMJ@UK.AC.ASTON.SPOCK) ------------------------------ Date: Thu, 11 Apr 91 22:41:15 edt From: astre@halfog.asrc.albany.edu (A.S.T.R.E.) Subject: Flash & QuickST To: info-atari16@naucse.cse.nau.edu Steven, I've seen that problem, too. I'm using Flash 1.62 and QuickST 2.00 on a monochrome monitor. It seems to be a problem with VT-52/100, as I think I've also seen it occur with UniTerm and Atari's VT-52 emulator DA. It's not that bad if the screen is scrolling (basically it leaves a big ugly cursor mark somewhere every few lines), but it's a nuisance otherwise (anyone play Axotoxl [sp?] Football League on BBS's? big problem there!). My solution is to use SuperBoot to configure my auto/DA files so that, if I'm going to be telecomming ------------------------------ Date: Thu, 11 Apr 91 22:48:06 edt From: astre@halfog.asrc.albany.edu (A.S.T.R.E.) Subject: Flash and QuickST, continued To: info-atari16@naucse.cse.nau.edu ...sorry we were interupted if I'm going to be telecomming, I have a particular keystroke set to GEMSTART Flash and *not* to \AUTO\ QuickST. Once I'm done, I reboot (va UIS warm reboot) and select a config with QuickST running. With a HD, it only takes about 10-15 seconds and a few keystrokes, so it's not too bad. The moral of this story is: try out SuperBoot (ver. 7.0 was just released about a month ago) if you need to reconfig your \AUTOs or DAs to get around this (or if you use GDOS or if you use OMNIRES or if...) ////////////////////////////////////////////////////////////////////// // Jeff Vincent / ASTRE // ASTRE = Competition Rocketry // // astre@halfog.asrc.albany.edu // Publisher of STAR-DATE // //------------------------------------------------------------------// // "So, like, do you guys ride in these things?" // ////////////////////////////////////////////////////////////////////// And it wouldn't hurt if one (or both) of us sent a bug report to Darek... ------------------------------ Date: 12 Apr 91 06:27:06 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!petunia!csuchico.edu!ekrimen@arizona.e du (Ed Krimen) Subject: Forem BBS for sale To: Info-Atari16@naucse.cse.nau.edu $30 takes it. Willing to trade. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0 ------------------------------ Date: 12 Apr 91 06:31:01 GMT From: noao!asuvax!cs.utexas.edu!swrinde!mips!spool.mu.edu!munnari.oz.au!goanna!minyos .xx.rmit.oz.au!s882854@arizona.edu (Tehn Chin) Subject: Okami English manual To: Info-Atari16@naucse.cse.nau.edu Have just downloaded the Okami Shell from atari.archives. I am slightly confused in using it as the manual is in German. I was wondering if there is a english version of the manual. Thanks in advance. Reply via news group -------------------------------------------------------------------------- Tehn Yit Chin s882854@minyos.xx.rmit.OZ.AU "Don't take any shit from anyone!" - Billy Joel, Live at Yankee Stadium -------------------------------------------------------------------------- ------------------------------ Date: 12 Apr 91 08:47:40 GMT From: munnari.oz.au!uhccux!uhunix1.uhcc.Hawaii.Edu!kiki@tcgould.tn.cornell.edu Subject: PgC 7600 details To: Info-Atari16@naucse.cse.nau.edu The following information is from the international edition of BYTE magazine's March '91 issue. Back issues are available by calling BYTE at (603) 924-9281. The international edition adds about 150 pages to the U.S. version of BYTE and contains many ads and product announcements of firms participating at the CeBIT Hannover Fair. Two articles by Dick Pountain, Byte's contributing editor in London, concern the PgC 7600 RISC and the Taos multiprocessing OS. The PgC 7600 is touted as a second-generation RISC processor capable of 160 MIPS, Intel 80x86 emulation and embedded control. The chip will reportedly sell, in quantity, for $20. The Taos OS may also be of interest to this newsgroup, not only because of its ability to run identical code on different processers, but also because it in- fluenced design changes in the PgC 7600 processor. One of the architects of the Taos OS, Chris Hinley, is also experienced in writing games for the Atari ST and Amiga (Verminator and Onslaught). His technique of using object-oriented assembly language with a large number of macro libraries in game design was used in the construction of Taos. A fellow programmer, Nick Spicer, is using his knowledge of transputers to implement parallel processing capabilities. For further information, refer to the article starting on page 90IS-117 of the international edition of the March '91 BYTE. The following article on the Pgc 7600 is actually about three pages long. -------------------------[excerpt of PgC 7600 article]------------------------- [ The PgC 7600 RISC processor is the result of a collaboration between Chris Shelton and Sir Clive Sinclair, two computer designers. Shelton is known in the U.K. as the designer of the Nascom and SigNet computers. The Nascom was a single-board computer, while the SigNet allowed multiple users to connect with a network of close-coupled Z80 processors. Sinclair is known worldwide for his inexpensive, yet capable microcomputers, as well as many other inven- tions. Sinclair and Shelton's goal is to produce an ultra-low cost workstation by basing it on a chip that integrated computational, memory and video RAM con- trol, networking, and timer logic. ] The processor, code-named PgC7600, has been in development since 1988 by a small team led by Shelton and financed mainly by Sinclair. Computer simu- lations of the chip were completed by July 1989 and masks for making it by March '90. First samples failed because of a process fault, and second samples revealed a flaw in the RAM interface. I had timed this article to coincide with the delivery of third (working) samples of the chip, but these have been delayed. Hopefully, a PgC7600 will be running by the time this article is published. The key idea behind its design is that speeding up a RISC processor eventually takes you to a point at which you cannot keep up with getting signals on and off the chip. Shelton therefore decided to isolate the RISC CPU by completely surrounding it with on-chip peripheral-control units that handle all the comm- unications with the outside world (e.g., memory accesses, interrupts and I/O channels). The PgC contains on-chip timers video RAM support, interrupt vector generation, DMA, an I2C bus for LANS, and a memory controller (MCU) which can refresh dynamic memories. All the PgC's interfaces to the outside world have been optimized for speed. For example, the chip uses unbuffered static-column mode for RAM accesses and a small but ingenious on-chip cache (called the Q-cache) to keep the processor fed with instructions. In addition, to further improve the memory bandwidth for instruction fetches, the PgC has a simple RISC core processor with about 100 instructions, almost all of which are 1 byte long. To achieve the performance (in excess of 160 MIPS) that he believes is required to emulate other commercial CPUs in software, Shelton is implementing the PgC 7600 in a bipolar process. Because of its high power consumption, however, bipolar technology has been completely supplanted by MOS technologies. It does have its advantages: it is faster than MOS and scales down better to submicron sizes. Also, because it is current-switching rather than voltage- switching, it can drive low-impedance loads like CPU pins faster than MOS can, bringing benefits in better CPU-memory bandwidth. PgC skirts the power con- sumption problem by reducing a logic transition to 0.25 volt instead of the standard TTL 5 volt, which reduces the energy dissipation by a factor of 400. The process that PgC uses is one originally developed by Ferranti (now Plessey- GEC), called the Collector Depletor Isolation (CDI). It offers access times of 2.5 ns at the modest 1.2 micron scale. The PgC7600 will be implemented initially as a gate array that occupies a 10 by 10 mm silicon chip, but this could be reduced to 7 by 7 mm with a custom layout. Some 33% of the chip area is RAM and ROM. In CMOS, Shelton believes that the 6000 gate chip could be implemented on a 2 by 2 mm die, but performance would fall to 60 or 70 MIPS. The bipolar process requires fewer masks than does CMOS, so PgC hopes this will help them produce the chip for $20 in quantity. This, in conjunction with the fact that it requires few glue-logic chips, could make it attractive as an em- bedded controller as well as an almost glue-less CPU for low-cost workstations. The prototype PgC7600 has an integer CPU that is expected to operate at about 160 MIPS. There is no on-chip FPU. The CPU is provided with 40 registers, divided into five banks of eight. All are 32 bits wide and can be accessed in 2.5 ns, giving a processor cycle time of about 5 ns. The register architecture is designed to be scalable in future versions while maintaining compatibility with earlier versions. To achieve this, the register banks are named 0, 1, 2, 3, and TOP. When an interrupt is serviced, state information such as the accumulator and pc contents are saved only in the TOP register bank. Designers could add more banks (numbered as 0, 1, 2, 3, 4, 5 and TOP) without causing programs written for earlier versions to break. The Q-cache is a fast (2.5 ns) on-chip RAM that is 32 bytes long and can, therefore, hold an average of 32 instructions. In hardware terms, the Q-cache is implemented as a circular buffer. During sequential program execution, it gets reloaded in single-word (32-bit) chunks, thereby acting as a 32-byte moving window into main memory. When a branch instruction causes the cache to become invalid, it gets reloaded in 64-bit chunks, and each chunk can start executing while the next one is loading. Like the register architecture, the Q-cache is transparently scalable for future chip versions. The MCU is described in PgC's documentation as aggressive, and this is no exag- geration. It controls most of the PgC7600's 84 external pins, and it features separate address and data buses. The MCU uses every possible technique to optimize access to ordinary DRAM, and it supports the static-column and fast- page modes of modern DRAM chips as well as SRAM. These modes (also supported by the Acorn ARM and Intel i860) typically allow 512 consecutive data words to be accessed from the same row of a RAM chip. For inexpensive 100 ns access- time DRAM chips, the row-address select cycle time may be as much as 180 ns, but the column-access select cycle is only 55 ns, becoming the effective cycle time. The PgC generates its CAS/RAS multiplexer signals on-chip, so they add only 3 ns to the cycle time. The use of a bipolar drive for the pins allows the MCU to access memory without buffering, saving even more time. The MCU is the only part of the PgC7600 that depends on external timing. With a 16 Mhz clock, it should achieve a 25 ns cycle time with 15 ns SRAM and a 50 ns cycle time with 80 ns DRAM, providing a bandwidth between 160 and 80 mega- bytes per second. Although the original requirements for the PgC7600 to act as a full graphics processor was abandoned, the final design can still act as an integrated CRT controller. A dedicated interrupt causes a jump into a ROM subroutine, which grabs a video address from the TOP register bank, puts it into the MCU, and then requests a VRAM access cycle. Control then returns to external code, which computes the next video address. If you put your video-synchronous sig- nal onto this interrupt pin, the PgC7600 becomes a CRT controller for video buffers implemented with VRAM chips. Shelton estimates that controlling a 1024 by 768 pixel by 8-bit video buffer in this way would consume about 1 per- cent of CPU time. The original purpose of the high performance promised by the PgC7600 was for full-speed emulation of other processors, especially the Intel 8086 family, in software, allowing the chip to drive a low-cost IBM PC-compatible work- station. However, PgC is now envisaging broader applications. Though the chip does not have special communication hardware like that of the Inmos transputer, its fast memory access would enable it to be used in parallel- processing systems where shared memory is the communication channel between processors. This sort of system would be ideal for running distributed message-passing operating systems such as Helios or Taos (see my article: "Taos: An Innovation in Operating Systems"). PgC has been in close contact with the developers of both operating systems and has even modified the instruction set of the PgC to better accommodate the Taos's message-passing scheme. As mentioned, the Pgc7600 has no hardware for floating-point arithmetic, which would seem to disqualify it from supercomputer applications. However, Shelton argues with some conviction that the superior processor-to-memory bandwidth can be exploited here. The Pgc7600 could feed floating-point data into pseudo- registers held in dual-ported RAM. From there, the data would be autonomously transferred into a streamed FPU, such as those from AMD, Weitek, or Cyrix, and the answers would be transferred back by the same means. Using 15 ns SRAM pseudo-registers, the PgC7600 should be capable of transferring data at 160 MBps (1280 Mbps). If each floating-point operation involved 100 bits, a three- operand scheme could sustain the quoted peak rate of the FPU, which could be up to 33 million single-precision floating-point operations per second. Combining this with the parallel scheme would allow pipelines of many PgC7600s to be con- structed to deliver supercomputer performance. Another intriguing possibility, given Sinclair's Anamartic connections, would be wafer-scale integration, for which the 6000 gate PgC design is an ideal can- didate. We'll see what happens. ----------------------------[end of excerpt]----------------------------------- For $20, this thing sounds potent, especially in combination with the Taos OS. The article alludes to the other ventures of Sir Clive Sinclair and I recall that he was supposed to be developing a silicon "hard drive", so that it is very possible that our conceptions of power and price may be radically altered. Though I don't question Sinclair's and Shelton's genius, I have some doubts about Sir Clive's business acumen. The Timex, Quantum QL, Cambridge Computer, and Psion are all pretty good machines, but they had some quirks and were not supported by further development. I think Atari might be in a better position to deliver and support a marketable product based on the PgC chips, because of their experience with the Inmos transputer and Helios OS, which culminated in the ATW computer. For the complete article, contact BYTE Back Issues, One Phoenix Mill Lane, Peterborough, NH 03458, (602) 924-9281. In Europe, send requests to BYTE Back Issues, c/o Dynamic Graphics International, P.O. Box 25, 3950 AA Maarn, The Netherlands. Jack ------------------------------ Date: 12 Apr 91 02:36:20 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.ed u!resst11@arizona.edu (Ryk E Spoor) Subject: PostScript printing To: Info-Atari16@naucse.cse.nau.edu Is there a program available anywhere that will take WordWriter output and convert it to PostScript, suitable for LaserWriters? Or, alternatively, is there a program that will take WordWriter output and convert it to either IBM WordPerfect or WordStar? (I have a publisher who'd be grateful if I could send the stuff in her own format) Sea Wasp ------------------------------ Date: 12 Apr 91 06:14:21 GMT From: noao!asuvax!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!ogicse!unmvax!uokmax!kllo ve@arizona.edu (Kenneth L Love) Subject: Shareware and programming To: Info-Atari16@naucse.cse.nau.edu I want to program a game or two this summer (see previous message for the language). Does anybody have any knowledge on the concept of shareware? Does saying it is so in a doc file constitute it being shareware? I would rather have the possibility of getting money for the time I spend programming, but it wouldn't be essential. That is what I consider to happen when someone releases a program as shareware. Is this what does occur? How often does someone get something and how good/useful does the program have to be before one would expect to receive anything back? That probably didn't make much sense (it doesn't to me and I just wrote it!), but I hope somebody understands it enough to reply. In case anybody is interested, one of the games I'm going to write is a solitaire game that I haven't seen anywhere (it's a LOT tougher than Klondike ever was). If you've ever played Spider then you have a good idea of the rules, except only one deck is used and only kings are allowed in "spaces". If anybody wants the rules (as taught to me), just send me some mail. (It really is one of the better solitaires, if you don't cheat a lot. When you do beat it, though... Well, you get the idea. It's also, IMHO, one of the most frustrating. I have had situations where 3 of the 4 suits had been removed from the board and was left with all the rest the cards in order [queen to ace], except the king was the last face-down card and the queen was sitting on top it. Since only kings can be moved to blank spots, I lost!) I haven't decided (yet) on the other game (it might not be a game for that matter). Anybody got any suggestions? (Please consider that this will be only my second program on the ST and in a language I will have only started to learn this summer. I consider myself fluent in Pascal, but ignorant in C.) Kenneth Love ------------------------------ Date: 12 Apr 91 02:35:20 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!munnari.oz.au!brolga!uqc spe!cs.uq.oz.au!warwick@arizona.edu (Warwick Allison) Subject: SIMPLE terminal emulator To: Info-Atari16@naucse.cse.nau.edu Is there a SIMPLE terminal emulator at atari.archive? I use Uniterm for most things, but I'd like a REALLY simple emulator for quickly switching back and forth from the command line (Mupfel) to the terminal emulator. I don't want any screen clears and stuff like that, just plain AUX:<->CON: type commumnication. Mupfel has a variable sized Console Window, but I can hack TERMCAP at the Uni end to correct for that. Alternatively, is there source to a fairly simple emulator that I can strip down somewhat? Thanks for any info! Warwick -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA. ------------------------------ Date: 12 Apr 91 08:29:35 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!samsung!olivea!mintaka!wookumz.gnu.ai .mit.edu!entropy@arizona.edu (entropy) Subject: SIMPLE terminal emulator To: Info-Atari16@naucse.cse.nau.edu In article <747@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au (Warwick Allison) writes: >Is there a SIMPLE terminal emulator at atari.archive? I use Uniterm for >most things, but I'd like a REALLY simple emulator for quickly switching >back and forth from the command line (Mupfel) to the terminal emulator. >I don't want any screen clears and stuff like that, just plain AUX:<->CON: >type commumnication. Mupfel has a variable sized Console Window, but I Look in the directory atari/mint and you will find 2 programs that should suit your needs, st52 by me and tip by Howard Chu. If you need any features at all, use Howard's program, as mine takes the expression 'dumb terminal' very literally. entropy ------------------------------ Date: 12 Apr 91 01:38:43 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-sta te.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!mts10271@arizona.e du (Michael T Stepniczka) Subject: SPURT To: Info-Atari16@naucse.cse.nau.edu Just a quick question- is the SPURT file that ended up at atari.archive incomplete? Should SPURT 1.0 have been included with it? If so, could someone who has it please send it to the archive site. Thanks. Michael Stepniczka mts10271@uxa.cso.uiuc.edu ------------------------------ Date: 12 Apr 91 04:44:40 GMT From: noao!ncar!elroy.jpl.nasa.gov!jarthur!petunia!csuchico.edu!ekrimen@arizona.edu (Ed Krimen) Subject: SPURT To: Info-Atari16@naucse.cse.nau.edu In article <1991Apr12.013843.8878@ux1.cso.uiuc.edu> mts10271@uxa.cso.uiuc.edu (Michael T Stepniczka) writes: > >Just a quick question- is the SPURT file that ended up at atari.archive >incomplete? Should SPURT 1.0 have been included with it? If so, could >someone who has it please send it to the archive site. Thanks. I sent SPURTDEM to a.a. When I got the archive originally, that's all it had. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0 ------------------------------ Date: 11 Apr 91 14:44:22 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!news-serv er.csri.toronto.edu!torsqnt!jtsv16!lsuc!jimomura@arizona.edu (Jim Omura) Subject: ST and RC stuff To: Info-Atari16@naucse.cse.nau.edu 1991/04/10 Atari ST and RC: 1. My article called "Bolink Rebirth" was published in the March 1991 issue of "Competition Plus". This is a magazine for Radio Controlled model car racing. The Atari 1040ST with Drafix 1 software and the Toshiba P321 printer are featured in that article as being the tools used to develop parts designs. 2. In the May 1991 issue of "Model Airplane News", Bill Griggs reviews the "R/C Aerochopper" simulator which runs on the Atari ST with a special dual, full proportional, joystick system. This simulator is distributed in the US by Futaba. 3. I received my update for Spectum Holobytes' "Falcon" F-16 simulator 2 days ago and I've run it on the 1040ST with TOS 1.4. It's working fine overall. The software still seems to have some operational rough spots. I've found that occasionally the disk "active" light will stay on when it shouldn't, but so far it's not happened in such a way that I couldn't "force" it off. This should NOT be necessary. I find this a bit discouraging. In dealing with a 3rd generation (version 1.2) of a commercial piece of software on a common and fairly standard system (the system was an unmodified 1040STF with TOS 1.4, an Atari original SF314 floppy and SC1224 monitor being the only active attachments), I don't think I should find fairly obvious functional bugs within the first minute of use. But aside from that I'm now having fun learning all about the F-16. According to the update erata sheet the "R/C Aerochopper" joystick system I mentioned above works with "Falcon". There's no mention of the STE 15 pin joysticks. One would hope that they'll have them supported in the future. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 12 Apr 91 05:47:54 GMT From: noao!ncar!unmvax!uokmax!kllove@arizona.edu (Kenneth L Love) Subject: The language named C To: Info-Atari16@naucse.cse.nau.edu This summer I'm going to be teaching myself how to program in C. My biggest (and brightest?) question is: "Which version of C is the best?". I realize that many factors could influence my (or someone else's) opinion. So, I'm going to list a few. The code must be somewhat portable between systems (i.e. Is there a standard and how far do the ST versions diverge from it?) The company support must be existant. Are there good books available for the learning of this version of C? (Or would any book on C be sufficient?) Would it be better if I knew something about the internals of the ST? (Is C like Pascal in that knowing the system hardware is uneccesary?) If I am fluent in Pascal, how difficult is C to learn? (Are they different conceptually? i.e. pointers = what in C? Does C have some things that Pascal doesn't? etc.) Is Turbo C going to be released in English? (I have NO desire to learn German, especially if all I was going to do with it was work with Turbo.) What kind of editor do the various versions use? (I like 'vi' over 'ed' anyday! :) (Is the mouse supported?) Does C use anything like a CLI or is it GEM only? (I use 'csh' on the Unix system here at Okla. U. Does C use a shell like 'csh'?) Can I use any of the versions of C without a hard drive? (I don't have one and it may be next fall before I do get one.) How much does the language(s) and book(s) cost? That's all I can think of. (I think I hear cries of, "Isn't that enough?"... Nahhh... Couldn't be! :) adTHANKSvance, Kenneth Love ------------------------------ Date: 12 Apr 91 06:21:06 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!unmvax!uokmax!k llove@arizona.edu (Kenneth L Love) Subject: The language named C To: Info-Atari16@naucse.cse.nau.edu In article <1991Apr12.054754.7583@uokmax.ecn.uoknor.edu> kllove@uokmax.ecn.uoknor.edu (Kenneth L Love) writes: > >This summer I'm going to be teaching myself how to program in C. My >biggest (and brightest?) question is: "Which version of C is the best?". > [ Stuff deleted ] > >adTHANKSvance, >Kenneth Love I forgot to mention that I would prefer to receive e-mail on this. I thought of another question: Does anybody have any well documented C source code for playing with graphics and sound on the ST? Would this probably be helpful in learning what the ST's ranges are? Should I get some other book(s) about the ST's capabilities? Thanx again, Kenneth Love ------------------------------ Date: 12 Apr 91 00:21:17 GMT From: fernwood!portal!atari!apratt@decwrl.dec.com (Allan Pratt) Subject: TOS 2.05 bugfix To: Info-Atari16@naucse.cse.nau.edu larserio@IFI.UIO.NO (LarsErikOsterud) writes: >While testing out my new MEGA STE i discovered a nasty bug in one >of the Xbios routines (I can't understand why no beta-tester has). Maybe because it's not a bug. >The XBIOS 5 call setscreen(logadr,physadr,resolution) >is used to set screen adresses and change screen resolution. >The routine does NOT wait for vertical blank as it i supposed to >but resets the video in the middle of the screen, causing the >picture to wrap around the left edge of the screen in 50% of >the cases. This does not look good (you get the edge of the >grapic screen in the middle of the monitor screen :-) Thank you for starting a panic. I think it is not a bug but a problem with your Mega STe. I can not reproduce the "bug" you report. It might have occurred to you that your Mega STe is to blame, not TOS. Your lack of understanding of the reasons for the protection code in the ROM has led you to a false conclusion. To nip this in the bud, I'll explain. The shifter mode must not be changed during a critical moment around vertical blanking. Previously that was avoided by waiting for the vblank interrupt, which ensures that the critical moment has passed. The new code uses another method: it checks to be sure that you are in the middle of the screen someplace, not in vblank. The upshot is the same: you avoid the window of vulnerability. If you had named the programs that caused trouble this would have been a more useful bug report. It is possible that there is an interaction between those programs and the new code. Please post or mail me the names of those programs. If this turns out to be a real live software bug, I will eat my words. (Lars-Erik has responded to me in mail about the programs (e.g. Degas Elite) and I have suggested that he return the machine to his dealer. This posting is for everybody else, so you don't think we're totally out to lunch when it comes to testing software.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ------------------------------ Date: 11 Apr 91 21:11:53 GMT From: fernwood!portal!atari!apratt@decwrl.dec.com (Allan Pratt) Subject: ZEST [really EMULA] To: Info-Atari16@naucse.cse.nau.edu Thank you for my smile of the day! > One word about EMULA, make sure you put this on a floppy AUTO folder >not your Hard drive, it does some funky stuff that will probably conflict >with other AUTOboot prgs and perhaps fry your Hard Drive. >Have Fun!!! Yeah, right. This is what I call quality software. Can't wait to run THIS program in my AUTO folder! Does anybody else consider this offhand caveat funny? ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ------------------------------ End of Info-Atari16 Digest ******************************